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(57) Abstract 

A bill editor, generator, messaging, and insert system and method comprises a portion of a bill production processor (15) designed 
to create monthly billing statements (28) which are sent to customers and which detail charges incurred over the course of a billing cycle. 
The bill editor and generator (151) allows billing personnel to design a bill using static text, dynamic text, and paragraph areas. Once the 
report/bill is defined, the report definition is stored in temporary memory for later use. The report definition file defines how the report is to 
appear and where the data used in the report is stored. The report generator, when subsequently run, uses the predefined report definition 
to retrieve data from the database and generates the report as defined by the report definition file. The bill messaging and insert system 
(152, 153) determines, based on assigned priority, criteria and weight and space limitations, the messages and notices to be included in a 
customer billing statement. 
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BELLING SYSTEM AND METHOD 

TECHNICAL FIELD OF THE INVENTION 

This invention relates in general to the field of data communication 
5 and more particularly to a system and method for the production of billing 
statements. 

BACKGROUND OF THE INVENTION 

Service and product providers must bill their customers. To do so, 
these service and product providers, such as cable television operators, local 

10 telephone service providers, long distance telephone providers, and credit 
card companies, must produce periodic billing statements for each of their 
customers. In the case of a cable television operator, each customer receives 
a monthly billing statement. A single cable television company may operate 
numerous cable television franchises in several geographic regions, covering 

15 millions of customers. Each of these customers receives a billing statement 
each month. 

Billing statements are often printed and mailed by bill Tenderers, 
which a service provider, such as a cable television operator, will contract- 
to produce its billing statements. In this arrangement, the service provider 

20 often furnishes die bill Tenderer with the customer data to be printed on the 
billing statements. 

Prior to printing the bills, they must be generated, edited and 
appropriately messaged. As far as generating the bills are concerned, it is 
necessary to determine where on the customer billing statement the various 

25 textual information is to appear. Ideally, the service or product provider 
would like to have the flexibility to change the format of the billing 
statement without having to physically type the textual information from 
scratch upon each change in the bill run format. Billing and reporting 
information traditionally has been presented in a format with little or no 
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flexibility for altering, without significant effort, the presentation of the 
information appearing on the bill or report. 

As far as bill messaging is concerned, it is necessary to include a 
variety of messages, notices and inserts with the bill. However, there are 
5 limitations on how much material may be included on a standardized billing 
statement, which usually consists of a perforated sheet of paper, a portion of 
which is returned with payment. When all of the messages will not fit on the 
available space on the bill, some of the messages are merely omitted, 
regardless of priority or importance. There is no known system for 

10 prioritizing the universe of messages that could appear on a bill and then 
print them on the available space according to their priority. In addition, 
there are weight considerations which must be observed to avoid having the 
customer billing statement exceed the cost of first class postage. 

These and other considerations are addressed by the bill generator, 

15 editor and messaging system and method according to the preferred 
embodiment. 

SUMMARY OF THE INVENTION 

It an object of the present invention to provide a bill editor and 
generator which is flexible in its ability to modify the format of the customer 
20 billing statement. 

It is a further object of the present invention to provide a bill editor 
and generator which facilitates the process of bill editing and generating. 

It is a further object of the present invention to provide a bill 
messaging system which prints notices and messages on a customer billing 
25 statement according to a predetermined priority in the space allocated on the 
billing statement for such notices and messages. 
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It is a ftirther object of the present invention to provide a bill insert 
system which provides inserts to the customer billing statement according 
to a predetermined priority without exceeding the cost of the prevailing 
weight limit of the preferred postal class. 

These and other objects of the invention are accomplished by a 
report/bill editor and generator and messaging system and method of the 
preferred embodiments. The terms bill and report are used interchangeably 
and should be understood as such. The bill/report editor and generator 
system and method comprises a single module in the bill production 
processor. The report editor is a graphical editor which allows a report 
designer to use a palette of tools to customize where data is to appear on a 
report or bill. The report designer will decide how the report/bill will 
generally appear, and using the tools, create a graphical layout of where the 
textual information will physically appear on the report. The report editpr 
accesses database catalogs which contain table names, table column names 
and stored procedures. The report generator facilitates generation of reports. 

The report designer has at least three types of tools to generate the 
report's layout, static text tools, dynamic text tools and paragraph areas. 
Static text refers to elements such as labels and heading appearing in the 
report and their geometries and contents as well. Dynamic text refers to data 
retrieved from the database. The dynamic aspects of the report editor and 
generator refer to the order in which the paragraphs are to be generated in 
the report, and the stored procedures used to retrieve the data. Finally, 
paragraphs and paragraph areas refer to areas allocated on the report where 
repetitive information is to appear. Once defined, paragraphs describe the 
mutual containment relationships of text. 
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Once the report editor has defined the layout of a report, a report 
definition file (RDF file) is stored in temporary memory. At some time in 
the future, the report may be run by a report generator program. The report 
generator program reads the RDF file from temporary memory. The RDF 
5 file describes how the report is to appear, where the data is stored and where 
it is supposed to draw the data on the report. The report generator queries 
the database under the control of the RDF file. The report generator pulls 
the data specified by the RDF file, and prints it in the manner specified by 
the RDF file. The report generator, on user demand, uses a report definition 
10 to get data from the database (and the user, if necessary) and generates the 
report defined by the report definition. The report generator can generate the 
report in any of the typical places supported on the native platform: screen, 
paper or disk. In other words, the user can specify that instead of printing 
the information on paper, it can be drawn in a window on a computer screen, 
15 or written to a file on a disk, which can be accessed at a later time without 
having to go back to the database. 

The bill message, notice and insert system and method comprises a 
bill definition portion followed by a bill run portion. The bill definition 
portion comprises a series of definitions which are input by the billing 
20 personnel whereas the bill run portion determines which messages, notices 
and inserts eventually make it into the customer billing statement. More 
particularly, in the bill definition portion, the billing personnel define the 
universe of available messages for a given billing cycle. The billing 
personnel also identify a universe of inserts available for the billing cycle. 
25 Each insert has a known weight. Next, the billing personnel define the 
criteria of information to be included on the bill. This could include account 
information, collections history, product history, etc. Next, the billing 
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personnel assign a priority to each of the messages, notices and inserts. In 
other words, the billing personnel interact with a system to specify the types 
of messages, the criteria of information to be included in that particular bill 
run and the associated priority of the messages and notices. The system then 
5 processes this information in the bill run portion to generate a bill which 
conforms to the weight and space limitations of the customer billing 
statement. 

More particularly, the bill run portion of the system then qualifies 
each message, notice and insert against stored information about each 

10 customer. Only messages, notices and inserts relevant to a particular 
customer qualify for that customer. The qualifying messages and notices are 
stored in temporary memory. Then, all of the qualifying messages and 
notices are arranged according to priority, and only those that fit on the bill 
are eventually printed. At the same time, all of the qualifying inserts are 

15 stored in temporary memory. Only those inserts which, according to the 
predetermined insert priority, will make the final bill equal to or less than the 
weight limit of the preferred postal class are included in the customer billing 
statement. 

Other objects, features and advantages of the preferred embodiments 
20 will become apparent when die detailed description is read in conjunction 
with the accompanying drawings. 
BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a graphical representation of the preferred embodiment 
system of the present invention indicating the data flow of the generation, 
25 messaging and printing of a billing statement. 
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FIG; 2 is a graphical representation of the bill editor and generator 
module of the bill production processor according to the preferred 
embodiment. 

FIG. 3 is a flow representation of the bill editor and generator module 
5 according to the preferred embodiment. 

FIG. 4 depicts a message generated by the bill editor and generator 
according to the preferred embodiment. 

FIG. 5 depicts a table generated by the bill editor and generator 
according to the preferred embodiment. 
10 FIG. 6 is a high level flow diagram of the bill messaging and insert 

system according to the preferred embodiment. 

FIG. 7 is a detailed flow diagram of the bill messaging and insert 
system according to the preferred embodiment. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
15 A service or product provider, such as cable television providers, 

local telephone service providers, long distance telephone providers, and 
credit card companies, store customer data on one or more databases within 
a customer management system. The customer management system 
manages the data comprising each customer account. As a customers 
20 account changes over time, as a result of, for example, service and product 
orders and deletions, the customer management system updates the customer 
data so that an accurate current and historical record is maintained of each 
customer's account history. FIGURE 1 is a graphical representation 

of a customer management system 10 of a service provider. A customer 
25 management system may include one or more data servers 12 connected 
across one or more communications links 13 to one or more customer 
databases 14. Databases 14 may be all located in one physical location or 
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may be located in separate physical locations. Each of data servers 12 is 
connected across one or more communications links 17 to a bill production 
processor 15, which processes and handles the customer data maintained in 
customer management system 10. 
5 The bill production processor system 15 of the present invention 

includes a bill editor and generator module 151, a bill messaging extraction 
module 152, a bill insert manager module 153 and a bill format manager 
module 154. All the customers of a service provider are not billed at the 
same time each month. A service provider will often bill its customers on 

10 a rolling monthly schedule so that different sets of customers, perhaps 
differentiated by geographic region, are each billed during different periods 
of each month. At the time of the month that a given set of customers is to 
be billed, bill production processor 15 extracts from customer databases 14 
the customer data that is to be printed on the billing statements provided to 

1 5 the billed customers. 

The input to the bill format manager module 154 is the unformatted 
customer data for each customer to be billed. The unformatted customer 
data provided at the output of bill format manager module 154 includes 
account status information, customer address information, account balance 

20 information, legal notices, promotional notices, and other data for each of 
the customers to be billed. 

Bill format manager module 154 receives the unformatted customer 
data from modules 151, 152/153 and converts this data according to a bill 
renderer definition format. The output of bill format manager module 1 54 

25 is the formatted customer data for the set of customers to be billed. The 
output of bill format manager module 154 is saved in a formatted customer 
billing file 20, which may be any suitable storage medium, including a tape, 
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disk, or optical storage medium. Formatted customer billing file 20 contains 
the formatted customer data for each of the customers to be billed. 

Formatted customer billing file 20 is provided to, one of any number 
of available bill Tenderers 22. A bill renderer interpreter module 24 (I) 
interprets the syntax of formatted customer billing file 20, which is formatted 
according to the bill renderer definition format, (2) extracts the customer 
data from formatted customer billing file 20, and (3) sends the interpreted 
and extracted data to a printer 26, which prints a series of customer billing 
statements 28. 

The output of bill format manager module 154 is formatted according 
to the bill renderer definition format. The bill renderer definition format 
provides a simple format for the service provider's customer data. The bill 
renderer definition format of the present invention is easily interpretable by 
the bill renderer interpreter module 24 of each of the service provider's bill 
Tenderers 22. 

With reference to FIG. 2 in conjunction with FIG.l, there is shown 
an overall schematic of the report editor and generator module 151. The 
terms "bill" and "report" are used interchangeably and should be understood 
as such. The report editor and generator has two separate components which 
work together to generate a bill. The first, report editor 15 1 1 , is the portion 
of module 151 directed to generating the graphical layout of a bill or report 
on paper or a screen. The second, report generator 1512, is the portion of 
module 151 directed to the generation of report based on the instructions 
contained within report editor definition file 1 5 1 3 . 

A user, at 15 14, using a palette of tools defines the overall layout of 
the report. When a particular tool is specified, whether it is static, dynamic 
or paragraph text, the report editor 1511 accesses database catalogs 1515. 
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The editor accesses the database catalogs to allow the user to choose the 
stored procedures which are run when the report is generated. In other 
words, the user 1514 selects the stored procedures to be used by the report 
for execution at a later time. Once the report is defined, it is stored in a 
report definition file (RDF file)1513. The RDF file 1513 is a temporary 
memory which stores the overall layout of the bill, but not specific customer 
data. 

When the billing personnel desires to run a bill, the report generator 
segment 1 5 1 2 of the system is run. The report generator 1512 reads the RDF 
file 1513, which describes how the report it to appear, where in the database 
15 16 the customer data is stored and where to draw the data on the report. 
The report generator 1512 queries the database 1516 under the control of the 
RDF file 1513. The report generator 1512 pulls the data specified by the 
RDF file 1513, and prints it as a report 1517 in the manner specified by the 
RDF file 1512. The user can specify that instead of printing the information 
on paper, it can draw it in a window on a computer screen, or write it to a 
file on a disk, which can be accessed at a later time without having to go 
back to the database 1516. 

With reference to FIG. 3, there is shown a schematic flow diagram of 
the steps used by the billing personnel to edit and generate a report. Report 
editor 151 1 is first used to define the appearance of the report. Then, report 
generator 15 12 is used to collect the appropriate information required by the 
report definition file 1513. In step 1560, the billing personnel lays out the 
graphical elements which will appear on the bill. These include static text 
elements of step 1562, which consist of unchanging text, such as field 
captions, labels, headings, etc. In addition, in step 1564, dynamic text 
elements are input by the billing personnel. Dynamic text is text that 
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depends on a table column or some other variable quantity, such as the 
current date, the current time, and page number. As is well known in the art, 
data in relational databases are organized in tables. For instance, the 
database may contain a customer table, which includes important 
5 information pertaining to the customer. Data in relational databases is 
generally organized in rows and columns. A specific customer in a customer 
table is typically represented in a single row, along which all of the 
information about that customer is stored. The columns of the customer 
table might include first name, last name, customer ID, current balance, etc., 

10 respectively. 

Next, the billing personnel in step 1566 defines the paragraph area 
scripts. Paragraphs are generated within paragraph areas. A paragraph area 
appears within a larger paragraph. Each paragraph in the report is associated 
with a particular paragraph area in the report, and may only be generated 

15 within that paragraph area. A paragraph area is divided into one or more 
equal width columns. A paragraph associated with a given paragraph area 
has a width equal to the width of either the paragraph area or one of its 
columns. The order in which paragraphs are to be generated in the report 
and the stored procedures that are to be called to retrieve data are in a 

20 paragraph area script. 

Paragraphs are generated within paragraph areas under the control of 
the script. Associated with each paragraph area is a paragraph area script, 
which constructs the paragraph area with the data obtained when the report 
generator 1512 queries the database 1516. The scripting language is 

25 preferably graphical, and there may or may not be textual representation of 
it. One example of a textual representation of the scripting language syntax 
is shown below. When all paragraph areas in a containing paragraph are 
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full, and another paragraph is generated in one of the paragraph areas, 
another page is generated for the report. 

Once the report is defined by static, dynamic and paragraph text, it is 
reduced to an RDF file at 1568 and stored in temporary memory 1513. At 
some later time, the billing personnel can generate the report. Upon 
instruction to do so from the billing personnel, the bill/report generator 1512 
reads the RDF file 1513, which describes how the report is to appear and 
where the data is stored in database 1516, The report generator 1512 
interprets the contents of the RDF file at step 1570 and. at step 1572 has the 
database execute stored procedures. Finally, the report generator 1512 pulls 
the data specified by the RDF file 1513, and prints it in step 1574 in the 
manner specified by the RDF file 1513. 

As is apparent from the foregoing, the RDF file is designed to 
provided support for specification of all manner of printed output, from 
traditional line-oriented reports, such as pay-per-view order summaries; to 
forms, such as bills and work orders. The RDF file features easy 
specification of repetitive or one-time outputs in units called paragraphs, 
with a natural connection to data sets modeled as the result sets of stored 
procedure calls to a relational database. Advantageously, RDF files are 
amenable to graphical editing. 

The following is a listing of RDF syntax and semantics. It consists 
of an alphabetical listing of productions, each defining the allowable 
representations of some nonterminal. The syntax is presented in a very 
stylized form. Nonterminals are in angle brackets; terminals are in boldface. 
Pseudoterminals are in italics, and are explained following the syntax. Text 
from a dash to the end of the line is commentary. Repetition of zero or more 
symbols is denoted by braces. Alternation between symbols is denoted by 
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15 



20 



25 



12 

a vertical bar. Numbers denoting origins and sizes are integer numbers of 
points, except where otherwise indicated. There are 72.27 points per inch. 

With one exception, line breaks are significant in this syntax and 
appear where shown. The exception is <page info>: due to space 
limitations, the representation of <page info> spans multiple lines, but in fact 
it must all appear on a single line. The distinguished symbol, i.e., the place 
to begin, is the nonterminal symbol <report>. 



<background color> 
<binding> 

<columns> 
<dynamic text> 



<element> 



<font> 

<foreground color> 
<fullwidth> 



- Color 

- - an identifier denoting a data element 
(see Appendix A) 

- - number of columns in paragraph area 
= DynamicText 

<binding> 

<ori x> <ori y> <width> <height> <justif> 
<background color> 
<foreground color> 
<font> 
= <dynamic text> 
<line> 

<paragraph area> 
<pictnre> 
<rectangle> 
<rounded rectangle> 
<static text> 
= Font 
- Color 

=■ - 1 if full width, 0 if column width 
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10 



15 



20 



25 



<grid size> 

<height> 

<justifi> 

<Iandscape> 

<line> 



<margin bottom> 

<margin left> 

<margin right> 

<margin top> 

<ori x> 
<ori y> 
<overlap x> 
<overlap y> 
<page info> 



<page info version> 



= - granularity of editing grid 

- - height 

= - 0 if left, 1 if center, 2 if right 
= - 1 if landscape, 0 if portrait 

- Line 

<ptl x> <ptl y> <pt2 x> <pt2 y> 
<background color> 
<foreground color> 
= - paper bottom margin 

(nonintegral number of points) 

- - paper left margin 

(nonintegral number of points) 

- - paper right margin 

(nonintegral number of points) 
= - paper top margin 

(nonintegral number of points) 
= - x coordinate of origin 
= - y coordinate of origin 

- 0 
= 0 

- <page info version> <paper type> 
<landscape> <poster> <paper width> 
<paper height> <margin left> <margin 
right> <margin top> <margin bottom> 
<scale mode> <scale x> <scale y> 
<overlap x> <overlap y> 

= a 
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15 



20 



25 



<paper height> 

<paper type> 
<paper width> 

<paragraph> 



< 



paragraph area> 



<paragraph identified 



<picture> 



<picture line> 
<poster> 
<ptl x> 
<ptly> 



14 

- height of paper 

(noriintegral number of points) 
= PaperType 

- width of paper 

(nonintegral number of points) 
: Paragraph 
<paragraph identified 
<full width> <height> 
<grid size> 

- number of elements 
{ <element> } 

ParagraphArea 

<script> 

<columns> <ori x> <ori y> <width> 
<height> 

- number of paragraphs 
{ <paragraph> } 

- a name uniquely identifying the 
paragraph within its paragraph area 
Picture 

<ori x> <ori y> 

- number of picture lines 

{ <picture Iine> } 

■ 64 hex digits of Neuron Data image data 
0 

- x coordinate of first point 

- y coordinate of first point 
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<pt2 X> 
<pt2 y> 

<RJDR version> 
<rectangle> 



< 



report> 



10 



<rounded rectangle> 



15 



<scale mode> 



15 



- x coordinate of second point 

- y coordinate of second point 
a 

Rectangle 

<ori x> <ori y> <width> <height> 
<background color> 
<foreground co!or> 
Report 

<RDF version> 
<page Info> 
<paragraph area> 
RoundedRectangle 

<ori x> <ori y> <width> <height> 
<background color> 
<foreground color> 
3 



<scale x> - 1 

<scale y> = 1 

20 <script> —a paragraph area script (see Appendix A) 

<statictext> = StaticText 

<text> 

<ori x> <orl y> 
<background color> 

25 <foreground color> 

<font> 

<text> t = - static text 
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<width> = -width 

Color = the name of a Neuron Data color resource 

Font - the name of a Neuron Data font resource 

PaperType 1 US letter 

2 US legal 

3 US tabloid 

4 US ledger 
etc. 

Associated with each paragraph area is a script, defining how each 
paragraph area is to be rendered. The syntax of paragraph area scripts is 
shown below. It uses the same stylized form as the above RDF syntax. The 
distinguished symbol (that is, the place to begin) is the nonterminal symbol 
<script>. 



<argument> 

<data set> 

<data set identifier> 

<expression> 

<foreach statements 



<paragraph identified 
<paragraph statement> 
<script> 
<statement> 

<type> 



<expression> 

<data set identified { <argument> } 
Identifier 

Identifier \ Number \ String 

| <type> ( <expression> ) 
foreach <data set> 

{ <statement> } 

end foreach 
String 

paragraph <paragraph identified 
{ <statement> } 

<foreach statement> | <paragraph 
statement> 

Integer | Money | String | Time 
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Identifier 



a sequence of one or more letters, 
digits, underscores, and periods, 
beginning with a letter, and not 
matching any of the above 
boldfaced reserved words may 
denote a data element, as <data 
set identifier^ <column name> 



Number 



a sequence of one or more digits 
a sequence of zero or more non- 



String 



10 



15 



20 



quote characters, in quotes 
When a paragraph area is to be rendered, the statements comprising 
its script are executed, in sequence. Execution of a paragraph statement 
simply consists of rendering its identified paragraph, at the next location 
within the paragraph area. Execution of a foreach statement consists of two 
actions: 

1) Acquire the data set of the foreach statement. In online 
operation, this involves calling the identified stored procedure 
with the listed arguments. In offline operation, this involves 
reading the next data set from an input file, where the data set 
consists of a number of rows m, a number of columns n 7 n 



2) For each row in the data set, execute the statements of the 
foreach statement, in sequence. 
Two examples of a typical RDF file follow. The reports specified by these 
examples are shown in FIGS. 4 and 5, respectively. The first example 
specifies a static message. 



column names, and m rows of data, n columns per row. 
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RDF: 

Report 
a 

a 1 0 0 614.295 794.97 72.27 72.27 72.27 72.27 3 1 1 0 0 
5 ParagraphArea 

paragraph "Paragraph 1" 

1 10 10 614 795 

1 

Paragraph 
10 Paragraph 1 

1 795 

6 
2 

StaticText 
15 Example I: 

72 205 

Color. White 

Color.Black 

fonts. FontLarge 
20 StaticText 

The simplest report you'll ever need. 

72 229 

Color.Transparent 
Color.Black 
25 fonts. FontLarge 

The next example, the output of which is shown in FIG. 5, displays 
data in a paragraph area contained within the top-level paragraph area. In 
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online operation, ihe stored procedure lp_£et_subject_cat is the source of the 
data elements subjectcatcd and subject_cat_desc. In offline operation, 
they come from an input file such as the one following the example. 
RDF: 
5 Report 
a 

a 1 0 0 614.295 794.97 72.27 72.27 72.27 72.27 3 11 0 0 
ParagraphArea 
paragraph " Paragraph 1" 
10 1 10 10 614 795 

1 

Paragraph 
Paragraph 1 
1 795 
15 6 

4 

StaticText 
Example 2 
205 96 
20 Color. White 

Color.Black 
fonts. FontLarge 
ParagraphArea 

foreach subject_cat paragraph "Paragraph 1" end foreach 
25 1 60 132 494 651 

1 

Paragraph 
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Paragraph 1 

1 36 

0 

3 

5 Rectangle 

20 0 468 37 

Color. White 

Color.Black 

DynamicText 
10 subject_cat.subject_cat_cd 

54 18 10 1 0 

Color.White 

Color.Black 

Font.Normal 
1 5 DynamicText 

subject_cat.subject_cat_desc 

271 18 11 10 

Color.White 

Color.Black 
20 Font.Normal 

StaticText 

Code 

120 120 

Color.White 
25 Color.Black 

Font.Bold 

StaticText 
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Description 
337 120 
Color.White 
Color.Black 
5 Font.Bold 

Input File: 

subjectcat 
10 11 2 

subject_cat_cd subject_cat_desc 

ADULT | Adult 

ADVEN | Adventure 

CHILD | Children 
15 CNCRT | Concert 

COMDY | Comedy 

DRAMA | Drama 

EDUC | Education 

FAM | Family 
20 HORR | Horror 

MUSCL | Musical Story 

SPORT | Sports 

With reference to FIG. 6 in conjunction with FIG.l, there is shown 
25 a high level flow diagram of the bill messaging extraction module 152 and 
bill insert manager 153 according to the preferred embodiment. The bill 
messaging extraction module 152 detennines the type of messages and 
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notices that may be included on a customer billing statement. The bill insert 
manager 153 determines whether inserts, if any, should be included within 
the customer billing statement based on the total weight of the bill. In Step 
1501 of the bill messaging, notices and inserts process of FIG. 6, the user 
5 first defines a universe of messages, notices and inserts which could be 
included in the customer billing statement. Step 1501 allows billing 
personnel to enter ah relevant messages, notices and inserts for a particular 
billing cycle, of which only a small subset may eventually appear in any 
particular customer's billing statement. Thus, by initially inputting a 
10 universe of billing messages, notices and inserts, the billing personnel is 
relieved of having to generate customized billing statements for each 
customer. 

In Step 1502, the universe of available messages are qualified for a 
particular customer, based on known criteria for that customer. If, of a 

1 5 universe of 50 messages, only 5 are relevant to, i.e., qualify for, a particular 
customer, the remaining 45 messages are discarded. 

Next, the messages and inserts are analyzed in Step 1503 to determine 
whether they will conform to the particular format established for that bill 
run. A particular bill format is chosen, perhaps consisting of a single, folded 

20 page, which is perforated so that the bill may be separated into two sections, 
one of which is returned with payment. All of the qualifying messages may 
not fit on the customer billing statement. Step 1503 determines whether 
particular messages will indeed fit on the chosen format for the customer 
billing statement. For instance, in the case of messages, this means that, of 

25 5 relevant messages, perhaps only 3 will fit on the final statement. Similarly, 
for notices, this means that only the most important notices will be included 
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in the bill, but only if the total weight of the bill is equal to or less than a 
designated postal weight, e.g., one ounce. 

Next, in Step 1504 all qualifying messages as specified through the 
formatting language transmitted to the bill renderer are printed and all 
qualifying inserts are stuffed into envelopes by the bill renderer. 

With reference to FIG. 7, there is shown a more detailed description 
of the bill modules 152, 153 according to the preferred embodiment. The 
system may be seen as having two operating segments, the bill definition 
segment 1510 and the bill run segment 1520, one following the other. In the 
bill definition segment 1510, the universe of possible messages and inserts 
are defined by the billing personnel. Once the universe of messages is 
determined, the bill run segment qualifies the messages for each customer 
and executes a prioritization to determine whether a particular message 
and/or insert will be included in the customer billing statement. 

In Step 1512, the billing personnel defines for the billing period the 
universe of messages that could be included on any given billing statement 
without regard to individual customer information. The universe of 
messages are preferably input using a graphical user interface. Alternatively, 
an existing or flat file with a predefined universe of messages is accessed by 
the billing personnel, who then chooses which messages are to be included 
in the sub-universe of possible messages. The types of messages that might 
be included within the universe are varied. For instance, if a customer 
currently subscribes to HBO, one of the messages might include the 
promotion "Free Cinemax in the month of December for all HBO 
subscribers, Happy Holidays!" Alternatively, the messages might be notices 
or reminders. For instance, it might remind customers to call "1-800- 
DONTDIG" for assistance concerning where to dig on their property to 
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avoid utility lines. Still further, the messages could be informational, such 
as informing customers of rate increases/decreases, informing customers of 
deadlines for solicitation of comments concerning changes in rules, 
advertising for an upcoming pay-per-view event, collections messages such 
5 as "your account is past due of $45.00, please pay immediately," etc. 

In Step 1514, the billing personnel identifies for the billing cycle the 
universe of inserts which could be included in any given customer billing 
statement without regard to individual customer information. The universe 
of inserts are input using the graphical user interface. The types of inserts, 
10 like the types of notices, are varied. For instance, they could include 
advertisements, legal notices, promotional coupons for local business which 
have paid for advertising on any of the cable stations, schedule of televised 
events, etc. 

After the universe of messages have been defined and identified, the 
15 billing personnel in Step 1516 defines criteria for determining which of the 
universe of messages, notices and inserts should be included in a particular 
bill run. The criteria is preferably defined by the billing personnel using the 
graphical user interface. Alternatively, the billing personnel could access a 
flat file having a listing of possible criteria, which are then chosen according 
20 to relevance to the bill run. The criteria of messages is diverse, and could 
include, for example, account information, collections history, product 
history, instructions to send messages and inserts to all customers, only to 
specified customers or some other subset of customers, instructions to send 
messages and inserts to those customers who have been late in remitting 
25 payment in the last three months, those in a certain zip codes, those 
subscribing to certain channels, etc., to name a few. The billing criteria is 
defined using traditional logic commands (AND/OR etc.) strung between the 
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various commands associated with the particular criteria. For instance, the 
criteria for a message could be designed as "All customers in franchise tax 
area 8010 AND in bill cycle 4 AND (have HBO OR Cinemax)". The step of 
setting specified criteria for a bill run is particularly useful in the case where 
a limited bill run is scheduled for a segment of the franchise's customer 
base. The remaining segment of the franchise would thus be excluded from 
the bill run. 

In Step 1518, the billing personnel assigns a priority to each of the 
messages, notices and inserts using, e.g., a scale of 1-10. This qualifies the 
importance of a particular message, notice or insert and the likelihood that 
it is included in a bill run. The higher the priority, the more likely a 
message, notice or insert will be included in a customer billing statement. 
For instance, government sanctioned legal notices would likely be assigned 
a relatively high priority, whereas advertising and promotional activities may 
be assigned a relatively lower priority. The billing personnel enters the 
priority of each of the messages, notices and inserts using the graphical user 
interface. With the conclusion of Step 1518, the bill definition segment 
15 10 is completed. No further input is required by the billing personnel. 

The bill run segment 1520 then commences. In Step 1522, each 
message, notice and insert, are qualified against stored information for each 
customer. Only messages, notices and inserts which are relevant to each 
customer individually qualify for that customer. For instance, if messages 
mforrning customers of imminent repairs in certain zip codes are included 
in the bill run, customers of other zip codes do not qualify and messages and 
notices are not sent to those customers in the non-qualifying zip codes. 
Alternatively, if Cinemax is offering a promotion, e.g., free Cinemax for 
customers with HBO, only those customers who currently subscribe to HBO, 
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but not Cinemax, will receive the notice on their customer billing statement. 
It is possible that 50 or more messages, notice and inserts will have been 
defined, but only 5 or less qualify for a particular customer. 

In Step 1524, all of the qualifying messages and notices are grouped 
together. Based on formatting rules, the messages and notices with the 
highest priority are designated to be printed on the bill first. As described 
previously in connection with the bill editor and generator module 151, 
different message areas are defined on the bill. The formatting rules dictate 
that the highest priority message that can fit into these areas are included on 
the bill. Since the bill is typically a single, perforated sheet, a limited amount 
of text space is available. If all of the available space on the customer billing 
statement has been allocated to messages and notices of relatively high 
priority, any remaining lower priority, un-printed messages are discarded. 
Alternatively, any of the remaining lower priority, un-printed messages may 
be stored in the customer's file for incorporation into the next billing run, 
and depending upon whether they are high enough in priority relative to the 
messages and notices for the next succeeding billing run and are not 
otherwise outdated, they may then be printed on the following customer 
billing statement. 

In Step 1526, all of the qualifying inserts are grouped together. First 
class postage is typically limited to a specified weight limited, e.g., one 
ounce. Anything above this will require further postage fees. When it is 
considered that tens of thousands of customers must be sent customer billing 
statements every month, the cost of mailing customer billing statements 
becomes significant. Thus, any deviation above the weight limit of first 
class postage becomes economically significant on this scale. At the same 
time, however, if a number of inserts qualify for a particular customer, it is 
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desirable to include as many inserts as possible without exceeding the first 
class weight limit. Thus, in Step 1526, the qualifying inserts are chosen 
based upon the assigned priority until the total weight of the bill is equal to 
or less than the prevailing weight limit of the preferred mailing class, i.e., 
5 one ounce in the case of first class postage. Any of the remaining lower 
priority inserts which are not included in the customer billing statement may 
be stored in the customers file for incorporation into the next billing run, 
and depending upon whether they are high enough in priority relative to the 
inserts for the next succeeding billing run and are not otherwise outdated, 
10 they may then be included in the following customer billing statement. 

Although the present invention has been described in detail, it should 
be understood that various changes, substitutions, and alterations can be 
made without departing from the spirit and scope of the invention as defined 
by the appended claims. 
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WHAT IS CLAIMED IS: 

1 . A method of preparing a customer billing statement comprising 
the steps of: 

defining at least one billing message to be included on the 
5 customer billing statement; 

defining criteria for including said at least one billing message 
on the customer billing statement; 

assigning a priority for each of said at least one message to be 
included on the customer billing statement; and 
10 qualifying each message for each customer based on stored 

customer information. 

2. The method of claim 1 further comprising the step of printing 
all qualified messages on the customer billing statement 

3. The method of claim 2, said printing step comprising the step 
15 of using formatting rules to print the highest priority messages that fit on the 

customer billing statement. 

4. A system for preparing a customer billing statement 
comprising: 

means for defining at least one billing message to be included 
20 on the customer billing statement; 

means for defining criteria for including said at least one 
billing message on the customer billing statement; 

means for assigning a priority for each of said at least one 
message to be included on the customer billing statement; 
25 means for qualifying each message for each customer based on 

stored customer information. 
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5. The system of claim 5, further comprising means for printing 
all qualified messages on the customer billing statement. 

6. A method of preparing a customer billing statement comprising 
the steps of: 

5 identifying at least one insert to be included in the customer 

billing statement; 

defining an insert weight limit for limiting the total weight of 

inserts to be included in the customer billing statement; 

defining criteria for including said at least one insert to be 
1 0 included in the customer billing statement; 

assigning a priority for each of said at least one insert to be 
included in the customer billing statement; 

qualifying each of said at least one insert for each customer 
based on stored customer information; 
15 providing qualified inserts in the customer billing statement 

according to priority. 

7. The method according to claim 6 further comprising the step 
of limiting the weight of the customer billing statement, including inserts, to 
the maximum weight limit of a preferred postal class. 

20 8. The method according to claim 7, said limiting step comprising 

the step of limiting the weight of the customer billing statement, including 
inserts, to one ounce. 

9. A system for preparing a customer billing statement 
comprising: 

25 means for identifying at least one insert to be included in the 

customer billing statement; 
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means for defining an insert weight limit for limiting the total 
weight of inserts to be included in the customer billing statement; 

means for defining criteria for including said at least one insert 
to be included in the customer billing statement; 
5 means for assigning a priority for each of said at least one 

insert to be included in the customer billing statement; 

means for qualifying each of said at least one insert for each 
customer based on stored customer information; 

means for providing qualified inserts in the customer billing 
10 statement according to said assigned priority. 

10. A method of editing a customer bill comprising the steps of: 
defining at least one static text element to appear on the bill; 
defining at least one dynamic text element to appear on the 

bill; 

defining at least one paragraph script area on the bill, said 
static text elements, dynamic text elements and paragraph script area 
comprising a report definition; and 

storing said report definition as a report definition file in 
temporary memory. 

20 n - The method of claim 10, said step of defining static text 

elements comprising the step of accessing database catalogues having a 
plurality of static text elements which can appear on the bill. 

1 2. A system for editing a customer bill comprising the steps of: 
means for defining at least one static text element to appear on 

25 the bill; 

means for defining at least one dynamic text element to appear 

on the bill; 



15 
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means for defining at least one paragraph script area on the 
bill, said static text elements, dynamic text elements and paragraph script 
area comprising a report definition; and 

means for storing said report definition as a report definition 
5 file in temporary memory. 

13. A method of generating a customer bill comprising the steps 

of: 

defining at least one static text element to appear on the bill; 
defining at least one dynamic text element to appear on the 

10 bill; 

defining at least one paragraph script area on the bill, said 
static text elements, dynamic text elements and paragraph script area 
comprising a report definition; 

storing said report definition as a report definition file in 
15 temporary memory; 

retrieving said report definition from temporary memory;, 

interpreting said report definition to determine customer 
specific information to appear on the bill; and 

retrieving customer information from databases to gather 
20 information to be printed on the bill. 

14. The method of claim 13, said step of defining static text 
elements comprising the step of accessing database catalogues having a 
plurality of static text elements which may appear on the bill. 

15. The method of claim 13, further comprising the step of printing 
25 the bill to a screen. 

1 6. The method of claim 13, further comprising the step of printing 
the bill on paper. 
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17. A system for generating a customer bill comprising the steps 

of: 

means for defining at least one static text element to appear on 

the bill; 

5 means for defining at least one dynamic text element to appear 

on the bill; 

means for defining at least one paragraph script area on the 
bill, said static text elements, dynamic text elements and paragraph script 
area comprising a report definition; means for storing said report 

10 definition as a report definition file in temporary memory; 

means for retrieving said report definition from temporary 

memory; 

means for interpreting said report definition to determine 
customer specific information to appear on the bill; and 
15 means for retrieving customer information from databases to 

gather information to be printed on the bill. 
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CODE DESCRIPTION 

ADULT Adult 

ADVEN Adventure 

CHILD Children 

CNCRT Concert 

COMDY Comedy 

DRAMA Drama 

EDUC Education 

FAM Family 

HORR Horror 

MUSCL Musical Story 

SPORT Sports 



SUBSTITUTE SHEET (RULE 26) 



PCTAJS96/201& 



6/7 




Of UJ 



§ CO UJ 



CO 
Ll. 




i 1 

I 

SUBSTITUTE SHEET (RULE 26) 



WO 97/24680 



7/7 



o 

CM 

in 



L 



o 

to 



1 



<CL 
2UJ 

Q^UJ 
Ll. 



(/>£ 

< O CD 
LO ^ < 



CM 

m 



OJ 
CM 
If) 




PCTAJS96/20135 
1 



A 



CO 
LO 



J 



2f CD ^ fc O 



rv v-. 



CO 

In 



I 



cr z 
uj « 

UJ S 

UJ o 



<f (Tl M 

CO z o 

o o 
oo c>o 

(/) W 3 
UJ ^ 



CM 
LO 




LM tO O 

Q UI -> 



UJ 



o 

p 



£i UJ p □ „ 

d 5 



L 



I 

SUBSTITUTE SHEET (RULE 26) 



INTERNATIONAL SEARCH REPORT 



International application No. 
PCT/US96/20135 



A. CLASSIFICATION OF SUBJECT MATTER 
IPC(6) :G06F 15/00 

US CL :395/234 . m _ 

According lo International Patent Clarification (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification ayatcm foUowcd by classification symbols) 
U.S. : 395/201. 214, 230, 234, 235, 239, 240. 245, 761. 779, 784. 785. 786. 792, 793, 805, 101 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name of data base and, where practicable, search terms used) 
Please See Extra Sheet. 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category* 


Ciution of document, wilh indication, where appropriate, of the relevant passages 


Relevant to claim No. 


X 


US 4,552,349 A (LOOS ET AL.) 12 NOVEMBER 1985, see 
Abstract, col. 1, lines 18-52 


6-9 


A 


US 4,951,196 A (JACKSON) 21 AUGUST 4990, 
see Abstract 


1-17 


A 


GOLDMAN, John; EXPEDYNE Strategic Billing Services 
Launched' PR Newswire (New York, NY, US); s1 p1; 16 
JUNE 1993; see entire document 


1-5, 10-17 


A 


MCCANN, Nita C; BellSouth Subsidiary Offers Billing 
Services; Mississippi Business Journal (Jackson, MS, US); 
v15 n29 s1 p8; 19 JULY 1993; see entire document 


1-5, 10-17 



xj Further documents are listed in the continuation of Box C. | | Sec patent family annex. 



« -^t : f m T~ later document pMbtnhed fcftcr the nurrnanonal filing date or priority 

SpocaU ouefono* of cited document,. ^ ^ ^ fa ^^llictwhhtbo w lkrioab*cMxou*dc***ade>c 

a^.~~-*4 the general state of tho art which » not considered principle or theory undcttyinf the invention 
lo bo or* particular relevance 

*X* ^/w.tm^i of particular relevance; the claimed invention cannot be 

"H" earlier it i in— 1 pub talked oa or after the international tttinf dale coenidered novel or cannot be eonaidcrcd to involve an inventive step 

. . . * ik« document it taken ■ Irian 
*L" documc^wnftcn may throw doubts on priority cfean(s> or which it ™° 

cite, to catabliah ^p^ttcnoon date of another citation or other , y . document of particular relevance; the claimed invention cannot be 

apecami rem on (an apectfied) ooneidered to mvotvo an hxveatxve step when the document is 

■O- document icfemaf to on oral dkclooure. inc. cjdubnion or other conn>nted wi* o« or inor^^ 

^.^^ being oervioua lo a pcraoo Triilr*! 1 m the art 

•p* Hnn—^t ptHrrtKH prior Vt far kV^rvt^^** fi'^f daaa but later than document member of the tame patent family 


Date of the actual completion of the international search 
26 FEBRUARY 1997 


Dale of mailing of the international search report 

2 5 MAR 1997 


Name and mailing address of the ISA/US 
Commiftstoocr of Patents and Trademark* 

Box PCX 

Washington, D.C. 20231 
Facsimile No. ^(703) 305-3230 


Auuhor^c^ofrfcer 

^TCPHEN R. TKACS 
Telephone No. (703) 305 3800 



Form PCT/ISA/210 (second sheeiXJuly 1992)* 



INTERNATIONAL SEARCH REPORT 



International application No. 
PCT/US96720135 



C (Continuation). DOCUMENTS CONSIDERED TO BE RELEVANT 


Category 0 


Citation of document, with indication, where appropriate, of the relevant passages 


Relevant to claim No. 


A 


BELLSOUTH, CINCINNATI BELL: BILLING AGENTS FOR 
HIRE; Telco Business Report; 06 DECEMBER 1993; see entire 
document 


1-5, 10-17 


A 


FROM BORING TO BRILLIANT: OVERHAULING TELCO 
BILLING STATEMENTS; Telco Business Report; vl2 nI2; 05 
JUNE 1995; see entire document 


1-5, 10-17 


A 


US 5,459,860 A (BURNH1T ET AL.) 17 OCTOBER 1995 
see Abstract 


1-17 



Form PCTASA/210 (continuation of oooond shec*XJ»!y 1992)* 



INTERNATIONAL SEARCH REPORT 



International application No. 
PCT/US96/20135 



B. FIELDS SEARCHED 

Electronic data bases consulted (Name of data base and where practicable terms used): 
APS: 

bill, billing, statement, insert, fixed data, static data, variable data, dynamic data, customize, billing- data 
DIALOG; 

bill, billing, statement, insert, fixed data, static data, variable data, dynamic data, customize, billing data 



Form PCT/ISA/2I0 (extra aheet)(Ju1y 1992)* 



